What is Deno & Will it replace Node.js?

Table of Contents

#What is Deno.js?

A secure runtime for JavaScript and TypeScript.

Better version of Node.js

Learn According to the official webpage, what is Deno.js? Also check out the official 1.0 announcement blog post.

Well, Deno.js is a runtime for JavaScript (like the same Node.js is a runtime for JavaScript) and it’s actually developed by Ryan (the creator of Node.js).

So the person who invented Node.js shares an alternative to Node.js with us – why would he do that?

Well, Ryan Dhal (who is “this person” ;-)) has a couple of regrets about Node.js, and Deno is simply the “better version of Node.js” that fixes those issues.

Learn Node.js – The Complete Guide in Hindi

Node.js is The most important JS runtime you can learn right now. And your knowledge will help you with Deno a lot.

# Will it replace Node.js?

Node.js is getting used by thousands of (very large) companies, it has a huge ecosystem and a highly active community – Node.js isn’t going anywhere!

You don’t have to trust me by the way – you can also listen to Ryan.

But there are a couple of bugs in Node.js which could potentially be improved.

# What’s wrong with Node.js?

First of all, the most important thing is that with Node.js nothing is wrong. You can use it and just because it’s here, you should not move to Deno.

However, in Node.js there are a few weaknesses that could possibly be improved and Of course those weaknesses don’t necessarily matter.

Few Node.js Weakness:

Node.js is focused on JavaScript and doesn’t (natively) use static types
The import syntax is very specific to Node.js and not what we know from the browser (ES modules, URL imports)
Node.js does not embrace modern JavaScript features like Promises
Node.js is not “secure by default”

# Node.js is not “secure by default”

The last point Node.js is “not secure by default” sounds horrible and it’s easy to get this point wrong.

Absolutely, Node.js allows you to build secure applications.

Note: But, A Node script doesn’t have a built-in security model. To be precise, by default, every Node script has full access to your file system, your network, and your entire environment.

# How does Deno fix those problems?

In general, Deno can be used for the same things as Node.js. You can use it to develop web servers, utility scripts, etc.

But in Deno:

By default supports TypeScript – hence it’s a JavaScript and TypeScript runtime
Uses ES modules (with URL support) imports instead of its own module system
Modern JavaScript features like Promises or async iterables
Is “secure by default”

Let’s take a closer look at above points:

# By default supports TypeScript

Of course, The usage of TypeScript gives you extra type safety and might help you avoid a lot of unnecessary bugs.

Absolutely, You can write normal JavaScript code with Deno – but if you want, you can also switch to TypeScript at any point as the TypeScript compiler is built right into Deno.

For example, Let’s take the below code:


let message: string // TypeScript feature!
message = 'Hi, this is a deno alternative of the node.js'
console.log(message)

let message: string // TypeScript feature!

message = 'Hi, this is a deno alternative of the node.js'

console.log(message)

This code would fail when executed with Node.js but works with Deno.

As i already mentioned, it’s optional but if you want to use it, you don’t have to set up your own custom TypeScript project and compilation flow first.

# ES (ECMAScript) Modules

Node.js brings its own modules system:


const http = require('http')
const something = require('./custom-file')

const http = require('http')

const something = require('./custom-file')

We’ve got used to it but it’s very different from the browser we know:


import something from './someFile.js'
import { someFunction } from 'https://cdn.some-domain.com/custom-package.js' // yes, this works!

import something from './someFile.js'

import { someFunction } from 'https://cdn.some-domain.com/custom-package.js' // yes, this works!

or – directly in HTML of course:


<script src="https://cdn.some-page.com/some-package.js"></script>

In the browser, we use relative or absolute URLs. We don’t sometimes use module names and sometimes file paths (both are done in Node).

In addition, in Node projects, we use npm to manage our local packages. This tool downloads them and stores them (as well as their dependencies) in the node_modules folder. This folder can easily become very big and it’s actually an important part of Node’s module resolution system.

Indeed, the following code relies on express existing as a package in node_modules – it would fail if it would be a simple express.js file or anything like that.


const express = require('express')

const express = require('express')

But in Deno, it doesn’t need a package managing tool or folder like npm/node_modules.

Deno simplifies this. You simply work with ES Module imports (i.e. the syntax you know from browser-side JavaScript).

Your Deno code looks like this:


import { serve } from 'https://deno.land/std@0.50.0/http/server.ts'

import { serve } from 'https://deno.land/std@0.50.0/http/server.ts'

Deno imports the serve function from the server.ts package which is stored on some web server.

Deno automatically downloads and caches this package (and its dependencies) when your code runs for the first time.

# Modern JavaScript Features

Modern JS functionalities like Promises weren’t as important and big (and common) as they are today.

Node.js works a lot with callback functions – simply because at the point of time it was created.

Deno, being very new, of course is able to work around that and leverage all those modern features.

For example, you can spin a very simple web server with the following snippet code that uses “async iterables” (what is that?).

In Deno:


import { serve } from 'https://deno.land/std@0.50.0/http/server.ts'

const server = serve({ port: 3000 })

for await (const req of server) {
  req.respond({ body: 'Message from Deno!' })
}

import { serve } from 'https://deno.land/std@0.50.0/http/server.ts'

const server = serve({ port: 3000 })

for await (const req of server) {

req.respond({ body: 'Message from Deno!' })

}

Just as a Deno, here’s pretty much the same server, built with Node.js:


const http = require('http');

const server = http.createServer((req, res) => {
  res.end('Message from Node');
});

server.listen(3000);

const http = require('http');

const server = http.createServer((req, res) => {

res.end('Message from Node');

});

server.listen(3000);

#Security

As mentioned, Deno has “security built in”.

It does not mean that your Deno applications are always secure, no matter what you do!

It means that Deno scripts can’t do everything on your computer by default.

For example,


import { serve } from 'https://deno.land/std@0.50.0/http/server.ts'

const server = serve({ port: 3000 })

for await (const req of server) {
  req.respond({ body: 'Message from Deno!' })
}

import { serve } from 'https://deno.land/std@0.50.0/http/server.ts'

const server = serve({ port: 3000 })

for await (const req of server) {

req.respond({ body: 'Message from Deno!' })

}

If you run the above server script as below,


deno run my-server.ts

deno run my-server.ts

you’ll get an error message:

The script only executes successfuly once you use the right permissions:


deno run --allow-net my-server.ts

deno run --allow-net my-server.ts

In this case, --allow-net provides network access to the script. Similar permission flags exist for writing (--allow-write) and reading (--allow-read) files for example.

# So … What do you think? should you switch?

This doesn’t sound too bad. But it’s also very possible, that you have a look at this list of new features and you think: “This is nice but I don’t hate those things about Node.js”

Deno is extremely new. Version 1.0 was released on May 13th 2020. And just because it’s v1.0 does not mean that it’s finished and you should use it for your production apps.

Conclusion

You can play with it, explore yourself in it and its packages ecosystem and use it in your support projects, demos and smaller apps, of course.

But only time will tell if it will be accepted by larger companies and projects and whether the problems it solves for most other developers are also really problems with Node.js.

I recommend that you look into it absolutely for the moment but don’t switch right now.

Are you looking for Freelancer Web Developer? Submit a paid service request

Pradeep Maurya

Pradeep Maurya is the Professional Web Developer & Designer and the Founder of “Tutorials website”. He lives in Delhi and loves to be a self-dependent person. As an owner, he is trying his best to improve this platform day by day. His passion, dedication and quick decision making ability to stand apart from others. He’s an avid blogger and writes on the publications like Dzone, e27.co